MLOps レベル 1: ML パイプラインの自動化

from MLOps: 機械学習における継続的デリバリーと自動化のパイプライン

レベル 1 の目標は、ML パイプラインを自動化することにより、モデルの継続的トレーニングを実行することです。

これにより、モデル予測サービスの継続的デリバリーを実現できます。

新しいデータを使用して本番環境においてモデルを再トレーニングするプロセスを自動化するには、自動化されたデータとモデル検証の手順、およびパイプライントリガーとメタデータ管理をパイプラインに導入する必要があります。

以下の図は、CT 用の自動化された ML パイプラインの概略的な表現です。

https://gyazo.com/f28d7b6a64ce730cb79378c01979b325

図 3: CT 用 ML パイプラインの自動化。

特徴

図 3 に示された MLOps レベル 1 の設定の特徴は次のとおりです。

迅速なテスト:

ML テストの手順は統合されています。手順間の移動が自動化されることで、テストのイテレーションが迅速になり、パイプライン全体を本番環境に移行する準備が改善されます。

本番環境でのモデルの CT:

次のセクションで説明するライブパイプライントリガーに基づいて、新しいデータを使用して本番環境でモデルが自動的にトレーニングされます。

テストと運用の対称性:

開発環境またはテスト環境で使用されるパイプライン実装は、本番前環境と本番環境で使用されます。

これは、DevOps を統合する MLOps 手法の重要な側面です。

コンポーネントとパイプライン用のモジュール化されたコード:

ML パイプラインを構築するには、コンポーネントを再利用可能、構成可能で、場合によっては ML パイプライン間で共有できる必要があります。

したがって、EDA コードはノートブック内に存在できますが、コンポーネントのソースコードはモジュール化する必要があります。

また、コンポーネントは次の操作のためにコンテナ化するのが理想的です。

実行環境とカスタムコードランタイムを分離する。

開発環境と本番環境の間でコードを再現可能にする。

パイプライン内で各コンポーネントを分離する。各コンポーネントは、独自のバージョンのランタイム環境、異なる言語とライブラリを持つことができます。

モデルの継続的デリバリー:

本番環境の ML パイプラインは、新しいデータでトレーニングされた新しいモデルに予測サービスを継続的に提供します。

オンライン予測用の予測サービスとしてトレーニング済みで検証済みのモデルを提供するモデルのデプロイ手順が自動化されます。

パイプラインのデプロイ:

レベル 0 では、トレーニング済みモデルを予測サービスとして本番環境にデプロイします。

レベル 1 の場合、トレーニング済みのモデルを予測サービスとして提供するために自動的に繰り返し実行されるトレーニングパイプライン全体をデプロイします。

追加コンポーネント

このセクションでは、ML の継続的トレーニングを有効にするためにアーキテクチャに追加する必要があるコンポーネントについて説明します。

データとモデルの検証

ML パイプラインを本番環境にデプロイすると、ML パイプラインのトリガーセクションで説明した 1 つ以上のトリガーが自動的にパイプラインを実行します。

パイプラインは、新しいライブデータによって、新しいデータでトレーニングされる新しいモデルバージョンを生成することを想定しています（図 3 を参照）。

そのため、本番環境のパイプラインでは、次の想定される動作を保証するために、データ検証とモデル検証の自動化手順を実行する必要があります。

データの検証:

この手順はモデルトレーニングの前に必要です。モデルを再トレーニングするか、パイプラインの実行を停止するかを決定します。この決定は、パイプラインによって以下が識別された場合に自動的に行われます。

データスキーマスキュー:

これらのスキューは入力データにおける異常値とみなされます。

つまり、データ処理やモデルトレーニングなどのダウンストリームパイプライン手順において、想定されるスキーマに準拠しないデータが受信されていることを意味します。

この場合、パイプラインを停止して、データサイエンスチームが調査する必要があります。

チームは、パイプラインに修正やアップロードをリリースし、スキーマにおけるこれらの変更を処理する場合があります。

スキーマのスキューには、予期されない特徴を受信すること、すべての予期される特徴を受信しないこと、予期されない値の特徴を受信することなどがあります。

データ値のスキュー:

これらのスキューは、データの統計的プロパティの重要な変化です。

つまり、データパターンが変化しており、モデルの再トレーニングをトリガーして変化をキャプチャする必要があることを意味します。

モデルの検証:

これは、新しいデータでのモデルのトレーニングが正常に終了した後の手順です。モデルを本番環境に進める前に評価と検証を行います。このオフラインモデル検証の手順は以下の通りです。

トレーニング済みモデルをテストデータセットで使用して、評価指標値を生成し、モデルの予測品質を評価します。

新しいトレーニング済みのモデルにより生成された評価指標値を、現在のモデル（本番環境モデル、ベースラインモデル、その他のビジネス要件のモデルなど）と比較します。新しいモデルを本番環境に進める前に、現在のモデルよりもパフォーマンスが優れていることを確認します。

モデルのパフォーマンスがデータのさまざまなセグメントで一貫していることを確認します。たとえば、新しくトレーニングされた顧客チャーンモデルの全体的な予測精度が、前のモデルと比較して向上している場合でも、顧客リージョンごとの精度値に大きな差異が出ることがあります。

インフラストラクチャの互換性や予測サービス API との整合性など、デプロイするモデルを確実にテストします。

オフラインモデル検証に加えて、新しくデプロイされたモデルは、オンライントラフィックの予測を提供する前に、オンラインモデル検証（カナリアデプロイや A/B テスト設定で）を受けます。

Feature Store

レベル 1 の ML パイプライン自動化用のオプションの追加コンポーネントは、Feature Store の 1 つです。

Feature Store は、一元化されたリポジトリで、トレーニングと提供のために特徴の定義、保存、アクセスを標準化できます。

Feature Store では、特徴値の高スループットのバッチでの提供と低レイテンシのリアルタイムでの提供の両方の API を指定し、トレーニングとサービス提供のワークロードの両方をサポートする必要があります。

Feature Store は、データサイエンティストが以下を行うのをサポートします。

（同じ特徴や類似の特徴の再作成ではなく）エンティティ用に使用可能な特徴を見つけ出し、再利用する。

特徴とそれに関連するメタデータを維持することで、定義が異なる類似した特徴の使用を避ける。

Feature Store から最新の特徴値を提供する。

Feature Store を、テスト、継続的トレーニング、オンラインサービス提供のためのデータソースとして使用して、トレーニングサービングスキューを防ぐ。

このアプローチにより、トレーニングで使用される特徴が、サービス提供時に使用される特徴と同じになります。

データサイエンティストは Feature Store からオフライン抽出を取得して、テストを実行できます。

継続的なトレーニングの場合、自動 ML トレーニングパイプラインは、トレーニングタスクに使用されるデータセットの最新の特徴値のバッチをフェッチできます。

オンライン予測の場合、予測サービスは、リクエストされたエンティティに関連する特徴値（顧客の属性特徴、プロダクト特徴、現在のセッション集計特徴など）をバッチでフェッチできます。

メタデータ管理

ML パイプラインの各実行についての情報は、データとアーティファクトのリネージ、再現、比較のために保存されます。また、エラーと異常値のデバッグにも役立ちます。パイプラインの実行のたびに、ML メタデータストアは次のメタデータを保存します。

実行されたパイプラインとコンポーネントのバージョン。

パイプラインの各ステップの開始日時と終了日時、完了までかかった時間。

パイプラインのエグゼキュータ。

パイプラインに渡されたパラメータの引数。

パイプラインの各手順で生成されたアーティファクトのポインタ（準備したデータのロケーション、検証での異常値、計算された統計値、カテゴリ特徴から抽出された語彙など）失敗した手順によりパイプラインが停止した場合、これらの中間出力を追跡することで、すでに終了した手順を再度実行することなく、直近の手順からパイプラインを再開できます。

以前のモデルバージョンにロールバックする必要がある場合や、モデル検証の手順でパイプラインに新しいテストデータが提供されたときに以前のモデルバージョンに評価指標を生成する必要がある場合、以前のトレーニング済みモデルへのポインタ。

トレーニングセットとテストセットの両方のモデル評価の手順で生成されたモデル評価指標。これらの指標は、新しくトレーニングされたモデルのパフォーマンスを、モデル検証の手順で以前のモデルの記録されたパフォーマンスと比較するのに役立ちます。

ML パイプライントリガー

ユースケースに応じて、ML の本番環境のパイプラインを自動化して、新しいデータでモデルを再トレーニングできます。

オンデマンド:

パイプラインのアドホック手動実行。

スケジュールに従う:

ラベル付きの新しいデータは、ML システムで毎日、毎週、または毎月利用できます。再トレーニングの頻度は、データパターンの変更頻度、およびモデルの再トレーニングの費用によっても異なります。

新しいトレーニングデータが利用可能になったとき:

ML システムでは、新しいデータは体系的に利用できるのではなく、新しいデータが収集されてソースデータベースで利用可能になった時点でアドホックベースで利用できるようになります。

モデルのパフォーマンスが低下したとき:

モデルは、パフォーマンスの低下が目立つようになったときに再トレーニングされます。

データ分布の大幅な変化

（コンセプトの変動）。

オンラインモデルの全体的なパフォーマンスを評価することは困難ですが、予測を行うために使用される特徴のデータ分布の大きな変化は検知できます。このような変化は、モデルが古くなっていて、新しいデータで再トレーニングする必要があることを示しています。

課題

パイプラインの新しい実装が頻繁にはデプロイされず、少数のパイプラインのみを管理しているとします。

このような場合は通常、パイプラインとそのコンポーネントを手動でテストします。

また、新しいパイプライン実装を手動でデプロイします。

また、パイプラインのテスト済ソースコードを IT チームに提出し、ターゲット環境へのデプロイも行います。

新しい ML アイデアによるものではなく、新しいデータに基づく新しいモデルをデプロイするときに、この設定が適切です。

ただし、新しい ML アイデアを試し、ML コンポーネントの新しい実装を迅速にデプロイする必要があります。本番環境で多数の ML パイプラインを管理する場合は、ML パイプラインのビルド、テスト、デプロイを自動化する CI / CD 設定が必要です。